INTERWORKING NETWORK MAPS OF NETWORK MANAGEMENT AND 
ELEMENT MANAGEMENT SYSTEMS 

Field of the invention 
[001] The invention is directed to communication networks and in particular to 
synchronizing the network map of the network management system (NMS) with 
that of an element management system (EMS). 

Background of the Invention 
[002] Communication networks are comprised of heterogeneous network 
elements (NE) such as telecommunication terminals, switches, routers, 
amplifiers, etc. interconnected in various configurations by physical hardware 
connections, and the software used to send, receive and route the information 
between these NEs. Network elements are each a complex programmable 
system, including programmable subsystems and local memory for storing the 
respective programs and maintaining records of the operating history. 

[003] The current trend to integrate smaller networks of various technologies 
into global networks that extend over tens of thousands of miles, demands 
reliable and sophisticated tools for monitoring and controlling operation of a very 
large number of network elements, which are spread over a large geographical 
area. In addition to the challenge posed by the size of the network, topology of a 
telecommunications network is continually changing as equipment is added, 
removed, relocated and/or upgraded. Still further, network customers demand 
fast response to any service request: a corporate user of bandwidth which 
requests additional capacity will be severely hampered if the response is not 
prompt. 

[004] Driven by the need to develop and deploy highly scalable new services in 
a rapid and cost-effective manner, the network management systems (NMS) are 
rapidly evolving towards highly distributed, multi-vendor systems with open 
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interfaces that enable applications that are independent from the underlying 
transport technologies. A NMS receives real time information about status, 
operation and performance of the NEs and systemizes this knowledge such that 
communication problems can be detected, isolated and corrected, either 
automatically or by the maintenance personnel. A NMS is provided with a 
graphical user interface (GUI) that enables an operator to input commands and 
to interact with various network entities. 

[005] The NMS maintains a network map (also known as network view or 
network topology view) with hierarchical information about network topology, i.e. 
the equipment and connectivity data. Such maps show the NE location in the 
network indicating the node of residency, and eventually a node group to which 
the node belongs. A node group is a logical grouping of nodes and NE's, and 
may also include other node groups. This topological information changes due to 
network configuration changes; whenever the network topology changes, the 
NMS map must be modified accordingly to accommodate this change. 

[006] To keep pace with the ever-increasing size of networks, a NMS 
communicates with a plurality of element management systems (EMS). An EMS 
is similar in role to the NMS, except that it manages NE of a specific type, from a 
specific network provider or vendor. EMS's also have an important role in 
configuring, provisioning, operating and monitoring the network elements they 
manage. 

[007] An EMS may also maintain a map with hierarchical information about the 
topology of the sub-network it controls. As the number of EMS's in a network 
increases, it is a challenge to keep the NMS and EMS's in synchronization 
regarding the network topology. 

[008] In general, the alignment between the EMS and NMS maps is performed 
manually. This is however extremely time-consuming and cumbersome, not to 
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mention error-prone for even the smallest changes or reorganizations in the 
hierarchy, or the naming of the node groups in the hierarchy. For example, if 
each node's location in the node hierarchy on the NMS map is used to generate 
the location identifier of that node on the EMS map, then changing a group name 
is a complex task because a group may include dozen of network elements, and 
the name change requires changing the EMS location identifier of each NE in the 
group. 

[009] Map alignment is particularly challenging for EMS's that manage 
subscriber access systems; such an EMS can manage hundreds of subscriber 
access multiplexers (SAM). A SAM multiplexes the data received from the user 
ports into the network. Return data from the network is demultiplexed by the 
SAM for communication to the clients via the respective ports. The SAM also 
enables scaling-up the number of users by gradually populating unused ports. 
As an example, a DSL (digital subscriber line) communication network uses a 
DSL access multiplexer (DSLAM), which is typically located at a central office of 
the telephone network and includes multiple DSL modem ports for connecting 
multiple client modems. 

[0010] U.S Patent Application 2003/0140132 A1 (Champagne et al.) published 
on July 24, 2003 describes a method of updating network device information and 
synchronizing the NMS database with the configuration information maintained at 
a network device. The synchronization process can be initiated in the NMS in 
response to input from a network management client, and can also be initiated 
via a message from the network device at power-up or upon insertion or removal 
of a circuit card. As a result, the NMS sends an upload configuration request to 
the network device, and the network device responds by transferring a 
configuration file containing the current configuration information. However, this 
Patent Application does not disclose synchronization of NMS and EMS network 
views. 
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Summary of the Invention 
[0011] It is an object of the invention to provide a method for interworking NMS 
and EMS network view maps that alleviates totally or in part the drawbacks of the 
such existent interworking methods. 

[0012] It is another object of the invention to provide a method for automatically 
synchronizing the NMS and EMS databases whenever a network topology 
change is made. 

[0013] Accordingly, the invention is directed to a method of synchronizing a 
network management system (NMS) and element management system (EMS) 
topology maps in a communication network. The method comprises receiving at 
the NMS a user request for a hierarchy altering operation, the user request 
comprising topology change data; verifying validity of the user request, and, 
whenever the user request is valid: altering the NMS network map according to 
the topology change data in the user request; automatically sending, from the 
NMS to the EMS, a change request comprising the topology change data; and 
updating the EMS map according to the change request. 

[0014] In another aspect, the method according to the invention comprises: 
receiving at the EMS a user request for a hierarchy altering operation, the user 
request comprising topology change data pertinent to a network entity; 
automatically sending, from the EMS to the NMS, a change request comprising 
topology change data; at the NMS, verifying validity of the user request; and 
altering the NMS network map according to the topology change data in the user 
request whenever the user request is valid. 

[0015] Still further, the invention provides a NMS for a communication network, 
comprising: a network topology map comprising all network entities in the 
communication network and hierarchical information on location of the network 
entities; a user interface for enabling the NMS to receive a user request 
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comprising topology change data pertaining to a specified network entity; means 
for verifying validity of the user request; means for changing the NMS map 
according to the topology change data whenever the user request is valid; and 
means for generating from the user request a change request comprising the 
topology change data and automatically sending the change request to an EMS 
affected by the user request. 

[0016] In addition, the invention provides an element management system 
(EMS) for a communication network monitored and controlled from a network 
management system (NMS) maintaining a network topology map with all network 
entities in the communication network and with hierarchical information on 
location of the network entities. The EMS comprises an EMS topology map 
including a subset of network entities and hierarchical information on location of 
the network entities in the subset; means for receiving from the NMS a change 
request comprising topology change data; and means for changing the EMS map 
according to the topology change data. 

[0017] Advantageously, the invention enables improved operator efficiency at 
managing a communication network, particularly at keeping the NMS and EMS in 
synchronization. 

[0018] In the case of an error causing the NMS and EMS not to synchronize, 
the invention allows the user to manually reissue the synchronization request at 
any time for one node (the selected node), all nodes that are directly or indirectly 
part of a node group, or all nodes in the entire network. 

Brief Description of the drawings 
[0019] The foregoing and other objects, features and advantages of the 
invention will be apparent from the following more particular description of the 
preferred embodiments, as illustrated in the appended drawings, where: 




Figures 1a illustrates a communication network, showing an example of 
network nodes grouping; 

Figure 1b illustrates a NMS map for the example of Figure 1a; 

Figure 1c illustrates an EMS map for the example of Figure 1a; 

Figure 2a shows an example of a network manager entire network map; 

Figure 2b illustrates an example of the information to be entered by a 
network operator for creation of a network element; 

Figure 2c shows a new node creation form; and 

Figure 3 is a flowchart of the method of synchronizing the NMS and EMS 
maps according to the invention. 

Detailed Description 
[0020] Figure 1a shows an example of a communication network 100, 
illustrating a possible hierarchical grouping of the network nodes. In this 
example, network 100 includes nodes'1 (Na) and 1 1 (Nb) and two node groups 
NG1 , denoted with 5 and NG2, denoted with 5\ As indicated above, the nodes 
are grouped based on physical location or logical ordering, according to 
organizational rules used in the respective network. NG1 in this example 
includes nodes N11, N12 and N13. Nodes N21 and N22 are groups along with a 
node group NG3, denoted with 5", into node group NG2. In turn, NG3 contains 
nodes N31 , N32 and N33. 

[0021] Figure 1b shows a data terminal (a workstation) 2, with the network 
management system NMS 20 which enables network operator access for 
transmitting commands to the NMS and receiving information about operation of 
the network. The NMS 20 has a user interface 6 which performs well known 
functions, and which has additional functionality according to the invention. A 
graphical user interface GUI on terminal 2 enables displaying various network 
maps on the screen of terminal 2, such as an entire network map, or parts of the 
network, at various granularities, as requested. Interface 6 verifies validity of any 
user request for a hierarchy altering operation of the network map 10, by 
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verifying the correctness of the topology change data in the user request, as 
discussed later. 

[0022] NMS 20 maintains an updated view of the network it manages, as shown 
at 10 on Figure 1 b, and a second interface 7 that enables changes to the map. 
That is, NMS 20 maintains a network topology database 15, which keeps the 
hierarchical information about the network node groups, nodes and network 
elements. An entire network map 10 shows only the managed objects at the top 
level of the hierarchy on network 100 of Figure 1a, i.e. nodes Na, Nb and groups 
NG1 and NG2. Maps for each group at the immediately next level are shown in 
coarse dotted lines under the respective node group, and maps at the next level 
are shown in fine dotted lines under the respective node group. Maps of finer 
granularity such as maps with the network elements at a certain node and their 
connectivity can also be viewed. 

[0023] Still further, the NMS 20 communicates with one or more element 
management systems EMS using a third interface 8. Interface 8 performs (in 
addition to the traditional mode of operation) new functions according to the 
invention. This NMS interface 8 identifies the EMS(s) affected by the user 
request for the respective hierarchy changing operation. Also, interface8 
transmits automatically a change request to the affected NMS for user changes 
to the portion of the map managed by the EMS, according to the topology 
change operation. 

[0024] Figure 1c shows a data terminal (a workstation) 3 with an element 
management system EMS 30. As indicated above, an EMS manages NE's of a 
similar type, and it may also maintain a topology database ETD 35 with 
hierarchical information about the subset of network elements in the sub-network 
it controls. As well known, EMS 30 may be provided with a user interface 16 for 
enabling communication with the network administrator using the GUI on terminal 
3. According to the invention, this first EMS interface 16 also enables the EMS to 
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receive a user request with topology change data pertaining to a specified 
network entity in the sub-network monitored and controlled by the respective 
EMS. In addition, interface 16 disables any subsequent user requests involving 
topology changes for the same network entity received on terminal 3, for 
enabling user request pertinent to said network entity from one localized place. 

[0025] It is to be noted that Figure 1c shows a simplified scenario with one EMS 
managing all nodes of NG2. As indicated above, an EMS manages a subset of 
the network, and an NSM manages one or more EMS's. In the example of 
Figure 1c, all nodes in NG1 are managed by the same EMS 30. Other scenarios 
may also be envisaged. For example, one EMS could manage nodes N21 and 
N31 , and a second EMS could manage nodes N22 and N33. In this scenario, 
N32 can be managed directly by the NMS 20. It is to be noted interface 8 of the 
NMS 20 shown in Figure 1b is responsible with identifying all affected EMS's due 
to user operation and then updating each accordingly. 

[0026] Network operators may also access the EMS database 35 to view a map 
40 with the topology of the sub-network of interest on the GUI over a second 
EMS interface 17. A third EMS interface 18 enables communication with the 
NMS 20; pertinent to this invention is receiving from the NMS any change 
request affecting map 40, and transmitting automatically a user request for a 
hierarchy changing operation, if input from this EMS. 

[0027] Let us assume that for the example of Figure 1a, EMS 30 manages the 
sub-network of node group 5\ and that nodes N21 and N33 are access nodes. 
Access nodes are equipped with a subscriber access multiplexer (SAM) network 
element 25, which could be for example an ATM SAM (ASAM), used for enabling 
access to a plurality of users to communication network 100. In this example, 
map 40 of EMS 30 shows the SAM at nodes N21 and N33, while also providing 
the information that the node N33 is in node group 5". The workstation 3 with 
EMS 30 is also referred to as a SWS (SAM working station). 
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[0028] EMS 30 is also equipped optionally with means for cyclically checking 
the state of the EMS. Thus, if a change request is received from the NMS and 
the EMS is temporarily in an 'off state', the change request is stored and the 
EMS status is cyclically checked. Once EMS 30 is back 'on', the change request 
is provided to the second EMS interface 17 and map 40 is altered accordingly. 

[0029] According to the invention, the NMS disseminates all network topology 
changes to the respective EMS's for keeping the network management system 
map 10 synchronized with the element management systems maps 40. To this 
end, the NMS 20 sends automatic change requests to the EMS's whenever a 
network topology change is made at the NMS. As the changes are completed in 
the EMS's topology database, the EMS sends acknowledgements of the 
requests to the NMS. 

[0030] Examples of changes are equipment addition, upgrades, relocation and 
removal. Also, node group name changes are considered a change in the 
network topology, since these need also to be propagated to the EMS's. The 
above changes refer to node groups, nodes, and network elements. Automation 
of this process is particularly beneficial in the case of SAM nodes; a SWS may 
manage for example hundreds of subscriber access multiplexers, and manual 
updates are time-consuming, expensive and error-prone. 

[0031] Also according to the invention, any topological changes made on the 
EMS side, such as addition of a SAM, is automatically propagated to the NMS. 
Once a SAM is on the EMS and NMS maps, the EMS prevents the administrator 
from making any topological changes to that SAM. The NMS becomes 
responsible for any future changes, forcing the administrator to do the changes 
from one localized place. 
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[0032] Also, the invention provides more than just automating the EMS-NMS 
map synchronization. The challenging part of EMS-NMS map synchronization is 
for the NMS to verify that the request is valid for the EMS, before allowing the 
user to perform the change operation on the NMS map. 

[0033] Figure 2a shows an example of a network manager entire network map 
10 as seen on the screen of workstation 2, illustrating nodes 1 , V (e.g. Na and 
Nb for the example of Figure 1a), and node groups NG1 and NG2. Scroll bars 
21 , 23 may be provided as well known to enable viewing of all entities at this 
level (entire network level). A control toolbar 27 with well-known pull down 
menus such as "File", "Edit", "View", "Tools", "Window, "Help" is also provided. 
Additional pull down menus "Create" shown at 22, and "List" shown at 24, are 
provided on toolbar 27 for enabling the operator to effect the topology changes 
on the NMS map. The "Create" button 22will allow the user to add new 
equipment to the map, and the "List" button 24 allows the user to view all 
equipment matching a particular listing criteria. 

[0034] On the bottom of the screen, a map toolbar 24 with buttons 26 enables 
activating various commands on the respective map 10. Tool buttons allow the 
user to manipulate the view of the network map with operations such as Zoom 
In/Out, Change the selected object, View the color map and Traverse upwards 
the node group hierarchy. 

[0035] To the right of the screen, a field 45 may be provided for showing the 
hierarchical structure of the network 100, for enabling the user to select the 
display of the network entities at another level of interest. For the above example 
of Figure 1a, it could show nodes Na, Nb and node groups NG1 and NG2 at the 
entire network level. If desired, the nodes of node group NG1 (i.e. nodes N1 1 , 
N12 and N13) and/or the nodes of node group NG2 (i.e. N21, N22 and NG3) 
may be viewed under the respective group. At the next level, nodes N31 , N32 
and N33 may be viewed under node group NG3, etc. 
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[0036] Figure 2b illustrates an example of the fields of the SAM workstation 
network element list (SNEL) used for creating a network element, and in 
particular a SAM 25. It is to be understood that the drawing illustrates one 
preferred embodiment, but other arrangements of the SNEL may also be 
envisaged. For the general case, the EMS network element list is called ENEL. 
The SNEL includes in this example three main fields, namely field 4 with SAM 
information, field 6 with information pertaining to the OAM (operation 
administration and maintenance) interface at SAM, and field 8 with data on the 
OAM interface at element management layer (EML). 

[0037] Field 4 requires completion/selection of the SAM type 31 , name 32, and 
location 33; information such as release may also be required for fully identifying 
the NE type. Filed 4 also requires completion of information regarding which 
component of the current EMS controls the newly created NE, such as EML 
workstation name, EML process, and access control domain (SWS name). 

[0038] The OAM interface at SAM field 6 enables assigning an address to the 
NE being created on the respective network. For example, the IP address of the 
SAM should be specified at 34. Also, the user can specify whether or not the 
SAM node once created will be supervised by the EMS or will be unsupervised 
(an unsupervised SAM node can later be supervised and vise versa). Support 
for protocols (such as BOOTP and SNTP) can be enabled/disabled in this part of 
the form. In case the SAM node is managed in a different subnet than the EMS 
and management messages need to go through another router, the user can 
specify the IP of that 38 router and the subnet mask 36 to be used. 

[0039] The OAM interface at EML field 8 requires specification/selection of the 
Ethernet or ATM host card. An "OK" button 7 is used to confirm completion of 
NE creation, while a "Cancel" button 9 enables corrections, and the "Help" button 
launches customer documentation for this form. 
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[0040] Figure 2c illustrates a SAM creation form 41, entitled "New Node". When 
the administrator wishes to add a node to the NMS to manage, s/he selects an 
appropriate location of the node based on the existing node hierarchy and the 
organization rules used. The administrator then adds this new node at the 
respective hierarchical level (under a node group or at the entire network level) 
using map operations enabled on the NMS according to the invention. If an 
appropriate node group does not exist, the administrator can create it. 

[0041] SAM creation may be initialized from the NMS 20 with the group 
hierarchy information as a default value for the location name field 33. A user 
can create a SWS managed node by first issuing a "New Node" command under 
"Create" button 22 on the NMS map 10 (see Figure 2a). The SWS element 
management system EMS 30 is selected in a "Managed By" field 37 on the form 
41 . Then, by clicking on the "Proceed" button 39 on the form 41 , the SAM 
creation form shown in Figure 2b will have the "location" field 33 filed with the 
respective location information. Thus, if the SAM creation is initialized from the 
entire network map, field 33 is filed with 7" (root). If, for the example of Figure 
1a, NG3 is contained in NG2, the user invokes the "New Node" command in the 
map for NG3, then after clicking the "Proceed" button 39, the location field 33 on 
the SAM creation form in Figure 2b will be filled with 7Group2/Group3". 

[0042] If the user wishes to move a node, let's say node Na from the entire 
network map 10 to the node group NG2/NG3, the EMS list of network elements 
(ENEL) will show the new location for node Na as 7NG2/NG3" instead of 7". If 
then the user renames NG2 to NG5, the ENEL maintained by the affected EMS's 
will show the location name for Na as 7NG5/NG3". If the user then moves NG3 
right under the "entire network", the ENEL will show the location name as 7NG3". 
In essence, the location field will always contain the updates generated from the 
new group hierarchy on the NMS. 
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[0043] The NMS also enables the operators to create the SAM node into an 
appropriate node group as a result of the modification of the SAM location from 
the SWS EMS. In this case, new groups are created automatically if they do not 
yet exist. Thus, whenever the user creates a new SAM node from an EMS, the 
group in which the "create SAM" command was launched is used to create the 
default node location on the map of that EMS. Before saving this form and 
adding the SAM node to the EMS, the user may change the location if 
necessary. Once the user clicks on the "save" button 7. The new node location 
is sent by the EMS to the NMS, and the node is created in the appropriate group. 
The group hierarchy in which the SAM node is now located will be used to 
automatically generate the new location and be sent to the SWS EMS. 

[0044] Once a SAM is created on the EMS, the NMS becomes the master of the 
nodes location and the EMS 'freezes' the node location on the node configuration 
form. The only way to change this location is to use the NMS to move the SAM 
node to another group, or move or rename the node group in which the SAM 
node exists either directly or indirectly. 

[0045] Figure 3 is a flowchart illustrating the method of synchronizing the NMS 
and EMS maps according to the invention. In step 50, the operator performs a 
hierarchy altering operation on the NMS map, using the GUI. As indicated 
above, the change could be addition, upgrade, relocation or removal of a NE, a 
node, or a node group. A change may also be a node group name change or a 
node group relocation. On receipt of the change request, the NMS 20 identifies 
the nodes affected by the operation, and determines the set of EMS's managing 
these nodes, denoted with EMSi as shown in step 51. It is to be understood that 
a change may affect more than one EMS, and as such the maps for each of the 
affected EMS needs to be updated. 
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[0046] Next, the NMS verifies the validity of the request with respect to each 
EMS, as shown in step 52 for EMSi. Request validity is verified before sending 
the request to the EMS's, against a set of rules and limitations 60. 

[0047] Request validity verification is challenging because each EMS is 
specifically designed to manage a certain type of NEs, which may each have 
specific limitations. These limitations may include the allowable format of node 
names, a specified number of nodes allowed in an EMS span of control, the total 
length of the location identifier generated from the new SAM's location in the 
node group hierarchy, etc. Thus, if the user moves an SWS managed node from 
one group to another, moves a sub-group containing AWS managed nodes from 
one group to another, or re-names a group containing SWS managed nodes 
within the group hierarchy, the NMS will check first if the new group hierarchy 
does not contain any empty group names and that the resulting location identifier 
meets the other restrictions of that EMS. 

[0048] If the request is invalid, as shown by branch "No" of decision block 53, a 
NMS error message appears as a popup error window, and the respective 
operation is denied, step 54. The error messages may be as detailed as desired. 
For example, let us say that the user invokes the "New Node" command 26 from 
a group map with one of the parent groups in the hierarchy containing an empty 
name and sets the "Managed by" field 37 to SWS. After clicking on the 
"Proceed" button 39, the NMS will reject the node creation by displaying a popup 
window saying e.g. "Node creation failed. Enter a group name for one or more 
node groups to which the node belongs." 

[0049] The empty name check is applied to all node groups in which the new 
node is being created (both direct and indirect containment) up to the entire 
network map. An "OK" button can also be provided on the popup error window, 
and when the user clicks on it, the popup window could disappear and "New 
Node" configuration window 41 could still be active. 
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[0050] The check for an empty group name is also performed when renaming a 
group that contains SWS managed nodes. For example, the user may select to 
rename NG2. The new group's new name may be empty. However, the NMS 
will first check to see if an EMS managed SAM exists directly or indirectly in this 
node group. If it does, then an empty name will not be allowed and a popup 
window will appear saying e.g.: "The group name cannot be empty. Please re- 
enter the group name". As in the above example, the popup window has an 
"OK" button; when the user click on it, the popup window disappears and the 
original name of NG2 returns, to enable the operator to reselect a valid name. 
As shown in this example, the EMS enables restriction to naming of node groups, 
even though the name would have been valid from the perspective of the NMS. 

[0051] These rules also take into account the syntax and completeness of the 
request. Example of invalid requests are syntax errors, such as resulting location 
identifier strings that are longer than permitted for the respective field on the 
EMS, or that contain characters that are considered invalid by the EMS. Invalid 
characters are treated in a similar manner. 

[0052] For example, the NMS blocks creation of a node if one of the groups in 
the group hierarchy has characters 7" and T. In this case, these characters are 
considered valid from the NMS perspective as node group names, yet they are 
not valid from the EMS perspective; they cannot appear in the location field since 
these characters are reserved as separators. Thus, if the user invokes the "New 
Node" command from the NSM and tries to create an SWS managed node in a 
group map, and that group or any of its parent groups has an invalid name from 
an EMS perspective, then clicking on the "Proceed" button 39 results in a popup 
window displaying an error message. The error message could in this case be: 
"Node creation failed. The group hierarchy for the node cannot contain one or 
more spaces or special characters (excluding dashes and underscores)." By 
clicking on the OK button on the popup window, the window will disappear, as 
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well as the "New Node" configuration window. The user will have to rename all 
of the non-conforming node groups before being able to successfully issue a 
SAM create request on the EMS from the NMS. 

[0053] In addition, whenever the change relates to moving a SAM node, or if a 
node group that contains a SAM node is moved or renamed, all node location 
rules for the EMS on the respective SWS need to be validated. For example, the 
length of the new location name for each SAM node that resulted from a change 
as above should remain less than the maximum admissible number of 
characters, and must still contain no invalid characters. Thus, simply moving a 
node or a node group into another level of the network hierarchy would be invalid 
if the resulting node name string, which comprises the hierarchical location of the 
node after relocation, is too long. 

[0054] Since such an ample validation operation may be costly, and could affect 
the overall performance of NMS operations, an option to disable these checks 
may also be provided. This will allow the user to decide when to enable the 
checks for maintaining consistency between the NMS node group hierarchy and 
the location attribute of the SAM's on the EMS's, and when to disable these. 

[0055] After all the empty groups are named properly, syntax error corrected 
and completeness of the request finalized, the user can resume the hierarchy 
altering operation, step 50. 

[0056] If all checks pass (i.e. the change request is valid), as shown by branch 
"Yes" of decision block 53, the NMS changes the network map appropriately, 
step 55, and the location field 33 is populated with the appropriate (new or 
modified) location, based on the node group hierarchy from the "entire network 
map" 10. 
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[0057] Now, the change request is sent to the affected EMSi, as shown in step 
56. For example, a user may wish to change the name of node group NG2 
shown in Figure 1a. In the scenario shown in Figure 1c, where all nodes of the 
group are managed by one EMS, the name change request is sent to EMS 30. It 
is to be understood that if more than one EMS is affected by a change request, 
the NMS sends change request messages to all affected EMS's. For the above 
example with two EMS's managing the nodes of NG2 (one for nodes N21 and 
N31 , and a second one for nodes N22 and N33), two update requests are sent to 
the first EMS, for updating nodes N21 and N31 , and two other update messages 
are sent to the second EMS for updating nodes N22 and N33. 

[0058] In step 58, the EMS effects the change to its map, as discussed above in 
connection to Figures 2a-2c. When the change is completed in the EMS's 
topology database, the EMS sends acknowledgements of the requests to the 
NMS, step 61. 

[0059] Another issue to be considered in the verification step is updating the 
EMS in real time as the changes are being made. A delayed synchronization 
mechanism may also be provided optionally, with a view to handle the case when 
an EMS may be temporarily unreachable or too busy to make network map 
changes, as shown in dotted lines steps 57-59. In this case, the NMS checks in 
step 57 if the EMSi is operational. If yes, the change is readily implemented in 
the EMS map, step 58. If not, step 59, the request is stored and the NMS checks 
cyclically if EMSi is back. 

[0060] In another implementation of the invention, the NMS may not check the 
connection cyclically to the EMS, but provide the user with the ability to manually 
request an automatic resynchronization of the node group hierarchy of the NMS 
with the location attribute on the EMS. Such an operation may be applied to the 
entire network, to a particular SAM node, or to all SAM nodes in a subset of the 
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hierarchy maintained by the NMS (e.g. selecting a node group and issuing that 
request). 
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